Hi @Abdul-Majid10. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

Hi @swnsma,
Happy to see your response! As you suggest solutions for it, I also want to discuss another solution that came to my mind.

The solution involves adding a 4th argument (bool $includePrefix = false) to the getIndexName function. When its value is true, we can concatenate the prefix, similar to this.

Note: We can only pass includePrefix true when Key already created for other index.

This is just draft to discuss the solution.

@swnsma, Looking forward to your response.

Hi @Abdul-Majid10,
I like flight of your thoughts.

I would only ask to consider:

1. Maybe it better to make it as a separated method and call it in the places where we need
2. How to deal in cases in dynamic (e.g. we had index "column1_column2", after added "column1_column2_unq", later we deleted "column1_column2" - how to avoid that our 2nd unique index will be renamed back to "column1_column2"?).

Think that I don't like is that right now we generate index name based on the current DB state.
What if we do things vice-verse and:

1. By default, we generate name like "column1_column2_unq" with prefix
2. If name not found - we fallback if index with "old" name conversion exists - "column1_column2" (here it may need to make a smart check that existing index is exactly what we need and not just index with the same name, maybe to check if index type in schema and index type in db are matching).
3. If we found index with old name conversion and correct type - do nothing. Otherwise - create a new index with a new name conversion.

What do you think?

@Abdul-Majid10,

Actually, I have even better point to discuss:
Why don't use "referenceId" from db_schema.xml as index name instead of generating index name based on columns?
Right now it's kind weird that it ignores 'referenceId' in db_schema.xml, meanwhile it looks into db_schema_whitelist.json and search for exact name of the index as it in the DB.
If there are no underwater rocks, using referenceId should make behaviour consistent (maybe it would require to think about additional index name validation - length, pattern etc).